AI 進入開發流程後，開發者花在「從零寫出每一行程式」的時間會下降，閱讀、判斷、驗證與修正所占的時間則會上升。
過去由開發者自行撰寫程式時，程式碼會連同需求理解、設計取捨、除錯過程與上下文記憶一起形成。開發者知道這段邏輯為何採用目前的寫法，也記得哪些地方曾經討論、哪些設計曾經調整。
AI 協助生成程式後，這些背景不會自然附著在產出內容中，團隊需要重新確認設計意圖、使用情境與影響範圍。
程式碼生成速度提高後，閱讀量會先被放大。AI 可以一次產生多個檔案、測試案例、設定內容與文件草稿，讓單次變更涵蓋更多範圍。
開發者需要確認每個檔案的角色、每段邏輯的目的，以及這些變更和既有系統之間的關係。原本省下來的撰寫時間，會轉移到閱讀、理解與確認工作。
開發者的工作負擔也因此改變。手動輸入程式碼的比例降低，理解 AI 與其他成員產出內容的比例提高。
團隊若忽略這項變化，容易把產出速度直接視為交付速度。完整交付仍要經過理解、驗證、整合與維護，每一個環節都離不開開發者判斷。
AI 產出的程式碼常具有完整的外觀。命名合理、結構整齊、註解清楚，錯誤處理看起來也相當齊全。
這些特徵可能降低審查者的警覺。審查者若只檢查語法與格式，容易忽略需求理解錯誤、資料邊界不清、權限判斷不足，以及例外流程和現有系統規則不一致等問題。
審查工作因此成為 AI 開發流程中的主要控制點。程式碼審查需要確認這次變更是否解決原本的問題、是否符合驗收條件、是否改動不該碰觸的區域，以及是否提高後續修改成本。
這些判斷牽涉系統歷史、業務規則、架構方向與風險承擔，仍需要團隊根據既有脈絡做出決定。
審查者也需要把注意力放在變更意圖。當 AI 生成一段實作時，團隊要理解它採用了什麼方式解決問題。
同一項需求可以有多種實作方法，有些做法能在短期內完成任務，後續卻可能提高資料耦合、模糊模組邊界，或讓相似邏輯散落在不同位置。
審查流程應該同時呈現需求意圖、程式變更與驗證結果。拉取請求（Pull Request, PR）說明應交代 AI 協助的範圍、由開發者判斷的部分，以及測試涵蓋的主要情境。
審查者掌握這些資訊後，程式碼審查才有足夠脈絡判斷風險。
閱讀 AI 產出的程式時，開發者需要越過單行語法或局部函式，看懂程式背後的假設，包括輸入資料的結構、呼叫方的使用方式、錯誤處理的層級，以及既有系統提供的能力。
這些假設一旦錯誤，即使程式碼外觀看起來完整，也可能在整合或上線後產生問題。
抽象閱讀能力，指的是從程式片段辨識系統設計。開發者需要判斷一段邏輯屬於業務規則、資料轉換、流程控制，或基礎設施處理。不同類型的邏輯應放在合適的位置，也需要搭配對應的測試方式。
AI 生成的程式有時會把多種責任放進同一個類別或函式，使程式看起來方便，後續修改時卻需要處理更多相依關係。
這種能力也包含對變更影響範圍的判斷。當 AI 生成的程式修改資料模型、API 回傳格式或共用工具函式時，影響範圍可能超過目前的開發任務。
開發者需要沿著呼叫關係、資料流與部署邊界往外檢查，確認哪些功能、測試、文件與操作流程會受到影響，藉由這種閱讀方式理解整個調整。
AI 時代的開發者仍需要紮實的程式撰寫能力。開發者熟悉良好程式的結構、邊界與可讀性，才能辨識不合適的生成內容。
撰寫能力、審查能力與系統理解彼此連動，缺少其中一項都會讓 AI 產出變得難以維護。
AI 產出的程式常給人完成度很高的感覺，審查者第一眼看到這些內容時，容易認為實作方向大致正確，接著加快閱讀速度。
這種完整感會提高審查難度。程式讀起來流暢，仍可能沒有正確反映需求。AI 可能採用了錯誤的業務假設，也可能自行補上一套看似合理的例外處理。
審查者需要重新拆解這些內容，逐一確認每個判斷來自需求、規格與既有系統規則，或出自 AI 根據有限上下文做出的推論。
過去開發者閱讀同事撰寫的程式時，可以透過討論追問設計理由。AI 產出的內容缺少形成過程，審查者需要從程式碼反推實作意圖。再加上 AI 產生的風格若與團隊規範不符，導致審查者需要花雙倍時間確認邊界條件（Edge Cases）與程式邏輯。
閱讀也因此帶有更多推理工作，這段邏輯為何存在、這個條件從何而來、錯誤處理是否符合產品流程，以及資料欄位是否適合目前的使用方式。
AI 產出的完整感會降低團隊質疑需求的敏感度，讓人產生盲目信任與思考惰性。當 AI 產出的內容看起來越完整，審查者越需要保持仔細閱讀的能力，把看似合理的實作重新放回需求、架構與風險脈絡中檢查，確認每項設計決定都有明確依據。
程式碼除了是一組可以執行的指令，也會反映系統設計。某段邏輯放在哪一層、由誰負責呼叫、資料如何流動，以及錯誤在哪裡被處理，都會影響後續維護成本。
AI 可以根據提示產生程式，它能掌握的設計脈絡，仍受限於團隊提供的輸入內容。
當提示詞沒有清楚說明架構邊界時，AI 可能會採用最直接的完成方式。例如把業務規則寫進 Controller、讓資料轉換散落在多個 Service，或在局部功能中直接處理跨模組邏輯。
這些程式在短期內可以運作，等到需求變動時，團隊就需要花更多時間追蹤相依關係與影響範圍。
設計脈絡也包含系統形成過程中的歷史原因。有些區域曾因效能、安全、法規或資料一致性問題採用特殊設計。AI 無法直接理解這些背景，除非團隊將相關資訊記錄在文件、架構決策紀錄（Architecture Decision Records, ADR）或提示詞上下文中。
缺少這些資訊時，AI 產出的修改可能表面合理，放回既有系統後卻不符合原有設計脈絡。
閱讀 AI 產出的程式時，開發者需要確認邏輯是否放在合適的位置、是否遵守既有邊界，以及是否延續團隊已經接受的設計方向。這類審查需要足夠的系統知識，並在容易查閱的位置保留設計脈絡。
AI 可以在短時間內產生大量程式碼，也會直接增加審查負擔。
單次拉取請求若包含太多檔案、邏輯分支、測試與文件變更，審查者很難在有限時間內維持一致的判斷品質。閱讀進入後半段後，注意力容易下降，辨識風險的能力也會受到影響。
審查疲勞會讓程式碼審查變成形式流程。審查者可能只確認測試是否通過、命名是否有明顯問題、格式是否符合規範，接著批准合併。
這種方式處理小範圍變更時，仍有基本檢查效果。面對 AI 生成的大量內容時，錯誤假設、設計偏差與隱性耦合就可能被忽視，然後進入主程式碼。
大量變更也會降低回饋品質。審查者一次看到太多問題時，可能只會挑出最明顯的幾個地方留言。
開發者收到回饋後，也不容易判斷哪些問題只需要局部修正，哪些問題代表整體實作方向需要重新調整。
時間一久，團隊可能開始接受「程式能執行、測試有通過」作為合併標準。
AI 產出的程式碼進入程式碼審查時，審查者需要先確認這次變更要解決的問題。
若直接從程式碼開始閱讀，容易被完整的結構、命名與測試案例帶著走，最後只檢查局部寫法，卻沒有確認整體方向是否符合需求。
變更目的應對應到需求、驗收條件或缺陷修正說明。審查者可以先閱讀拉取請求描述，確認這次修改服務哪個使用情境、預期改變哪些系統行為，以及哪些既有行為需要保持不變。這些資訊越清楚，後續閱讀程式時就越有明確基準。
AI 生成內容也可能包含超出需求範圍的修改，例如整理周邊程式、增加額外欄位、調整錯誤訊息，或改寫既有工具函式。
這些變更若沒有對應到明確目的，就會增加審查成本。審查者需要判斷它們是否必要、是否應拆成另一個拉取請求，或先回到需求討論釐清。
程式碼審查可以先由開發者交代三項資訊：這次變更的目標、AI 協助生成的範圍，以及經過人工判斷的重點。這些資訊能避免閱讀方向被大量程式碼牽引。
AI 生成的程式碼不需要每一行都用相同強度審查。審查者應先辨識高風險區域，把時間放在最可能影響系統安全、資料正確性與使用者流程的地方。這種做法更符合 AI 產出大量增加後的審查情境。
高風險邏輯包含權限判斷、金流計算、狀態轉換、資料寫入、跨系統呼叫、批次處理與例外補償。這些區域一旦出錯，影響可能延伸到多個功能與流程。
即使測試已經通過，審查者仍需要確認條件是否完整、邊界值是否涵蓋，以及失敗情境是否有明確處理方式。
AI 能掌握常見實作模式，對團隊特有規則的理解則取決於上下文是否完整。
例如某個狀態只能由特定角色切換、某筆資料只能在特定時間點修改，或某個 API 失敗後必須保留原始交易紀錄。這些規則若沒有寫進需求或測試，AI 可能依照一般情境自行補完。審查者需要特別檢查這些隱含規則。
AI 生成程式時，也可能引入供應鏈與執行階段風險。例如引用不存在或未經審查的第三方套件、使用舊版 API 或不存在的參數，或依照局部提示詞產生看似可執行的程式，卻忽略全域流程中的死鎖（Deadlock）、競態條件（Race Condition）與異步併發風險。
程式碼審查的工作也應從逐行檢查，延伸到把錯誤轉成可重複執行的治理機制。
審查者發現某種錯誤模式後，除了在當次拉取請求留下意見，也要評估是否能將問題轉成測試案例、靜態分析規則、提示詞範本、提交規範、架構檢查條件，或是直接將規範寫進專案的 AI 上下文設定檔（Context Rules），讓 AI 在下次生成程式時就自動避免。
同類問題可以由流程攔截後，人工審查就能集中處理更複雜的意圖與風險判斷。
風險導向的審查也需要搭配自動化檢查。格式、基本型別錯誤、一般安全掃描與測試結果，可以先交由工具處理或使用 AI 協助分析。
人工審查則集中在工具難以判斷的區域，包括業務意圖、系統邊界、設計取捨與長期維護影響。
AI 生成程式時，多半會依照眼前任務尋找可行解法。這種方式可以加快局部功能的完成速度，也可能讓程式偏離既有架構方向。
程式碼審查因此需要確認這次變更是否符合系統分層、模組責任與資料邊界。
架構方向會落實在日常程式碼中。例如 Controller 是否只處理請求與回應、業務規則是否放在合適的服務層、資料存取是否經過既有 Repository 或資料存取介面，以及跨模組呼叫是否遵守既定契約。
AI 若把邏輯放在最方便的位置，功能可能可以執行，後續卻會增加相依關係與維護成本。
審查者也需要留意 AI 是否引入新的技術慣例。它可能新增一套錯誤處理方式、建立新的工具函式、採用不同命名風格，或引入新的套件處理原有機制已經能解決的問題。
這些變更單獨看來影響有限，累積後會讓系統出現多套實作方式，也會增加新成員理解與修改的成本。
可以讓程式碼審查與架構決策紀錄（Architecture Decision Records, ADR）、團隊開發規範及既有範例連在一起。審查者看到疑似偏離架構方向的變更時，可以回到這些資料確認判斷依據。
架構方向整理成可閱讀、可引用的規則後，AI 生成內容才比較容易被放進合適的位置。
AI 會快速產生大量程式碼，團隊需要控制每次進入審查的變更範圍，以免審查疲勞。
團隊可以限制 AI 生成內容的變更規模，讓每次拉取請求聚焦在單一意圖，並將格式調整、重構、功能變更與測試補強分開處理。
變更範圍縮小後，審查者能更快掌握修改目的，也能更清楚地判斷 AI 產出的程式是否符合需求與系統設計。
限制變更大小也能協助開發者整理思路。AI 一次產出大量內容時，開發者需要先完成第一輪篩選，移除不必要的修改，只保留和目前需求直接相關的部分。
這個過程會促使開發者重新理解生成內容，避免直接把整批結果交給審查者處理。
團隊可以建立簡單的拉取請求規範，例如要求每次拉取請求聚焦單一目標、避免混入無關重構，重大設計變更也需要附上背景與判斷依據。審查者看到這些資訊後，就不必從大量差異中推測開發者與 AI 的意圖。
審查疲勞常來自大量重複、判斷價值有限的檢查。格式是否一致、靜態程式碼分析是否通過、型別是否正確、測試是否執行，以及安全掃描是否發現已知風險，這些工作若全部依賴人工審查，審查者的注意力就會消耗在機械式確認上。
在 AI 高產出的環境中，團隊需要把這些檢查放進自動化流程。格式化工具、靜態分析、單元測試、整合測試、安全掃描與相依套件檢查，都可以在拉取請求進入人工審查前先執行。
審查者取得檢查結果後，就能把時間放在工具難以判斷的內容，包括需求意圖、架構邊界、資料正確性與例外流程。
自動化檢查也能讓 AI 產出提早收到回饋。生成內容出現明顯錯誤時，CI 可以先阻擋合併，開發者再將錯誤訊息、測試失敗原因與規格限制提供給 AI 修正。經過這一輪檢查後，進入人工審查的內容會少一些基本錯誤。
團隊也可以制定明確的審查規範，讓 AI 協助第一輪程式碼審查。這些規範可以包含命名慣例、分層責任、錯誤處理、測試要求、資料存取方式與高風險邏輯檢查。
當規範被寫成可重複使用的提示詞或審查清單後，AI 就能先依照規則掃過變更內容，標示可疑區域、整理可能風險，並提醒開發者補上說明或測試。
這種做法能把部分審查工作前移。開發者在送出拉取請求前，可以先讓 AI 依照團隊規範檢查一次，審查者收到的內容會比較清楚，也比較容易把注意力放在真正需要人工判斷的地方。
自動化負責先檢查固定規則，人工審查集中處理需要工程判斷的部分。低判斷價值的檢查前移後，程式碼審查才能保留品質把關、風險辨識與設計判斷的作用。
AI 生成內容需要搭配清楚的提交規範，審查者才能建立明確的閱讀方向。
若拉取請求只寫「使用 AI 產生功能」或「調整實作」，審查者很難分辨哪些內容由 AI 生成、哪些地方經過人工修改，以及哪些假設需要特別確認。資訊不足時，審查就會花費大量時間還原背景與推測意圖。
提交規範可以要求開發者在拉取請求中交代幾項資訊，包括這次變更的目的、AI 協助的範圍、人工修改的重點、主要驗證方式，以及需要審查者留意的風險。
這些內容不需要寫得很長，只要能讓審查者快速掌握變更脈絡與閱讀順序。
AI 生成內容也需要保留必要的形成脈絡。開發者若使用了關鍵提示詞、重要規格，或根據測試失敗結果調整實作，可以將相關資訊整理到拉取請求描述、專案文件或任務紀錄中。
審查者不需要閱讀完整對話，仍需要知道生成內容依據哪些規則、限制與修正結果形成。
提交規範可以降低審查者的理解成本。當每次 AI 產出都清楚交代來源、目的與驗證結果，程式碼審查就能減少還原背景的時間。固定格式也能建立一致的 AI 使用習慣，避免產出量增加後直接形成審查壓力。
下面是一份考量 AI 協助開發與生成內容所設計的拉取請求說明模板範例：
## 變更目的 (Why)
- **相關工單**：#[編號]
- **需求說明**：[簡述這次 PR 解決的問題、新增的功能或修復的缺陷]
---
## AI 協助與人工編修範圍 (AI vs Human Scope)
| 類別 | AI 協助生成內容 | 人工判斷與修改重點 |
| :--- | :--- | :--- |
| **業務/狀態邏輯** | [例：產生退款狀態機初步邏輯] | [例：補上手動併發鎖 (Locking) 與權限防護] |
| **API / 介面** | [例：產生 DTO 與型別定義] | [例：修正 AI 誤用的第三方 API 廢棄參數] |
| **測試案例** | [例：生成單元測試框架與測試資料] | [例：補上邊界條件 (Edge cases) 與極端數值] |
| **文件 / 註解** | [例：生成 JSDoc / API Doc] | [例：校正符合專案業務術語] |
---
## 高風險與架構考量 (Risk & Architecture Checklist)
- [ ] **權限與安全**：已確認未洩露敏感資料、無幻覺套件（Package Hallucination）或權限漏洞。
- [ ] **架構邊界**：變更符合既有分層架構，未將業務邏輯散落至 Controller 或 UI 層。
- [ ] **併發與交易**：若涉及資料庫變更，已驗證交易（Transaction）與失敗補償機制。
- [ ] **例外處理**：已確認 AI 補上的例外處理符合產品既有流程與日誌規範。
---
## 驗證與測試 (Verification)
- [ ] **自動化測試**：所有相關單元測試與整合測試皆已通過。
- [ ] **人工驗證**：[簡述手動測試情境，例如：模擬支付失敗時是否正常觸發補償機制]
---
## 給審查者的建議重點 (Reviewer Focus)
> [告訴審查者應該把重點放在哪裡，例如：「AI 產出的狀態轉移矩陣請重點檢查」]
- **重點審查區域**：`src/services/payment.ts` 中的 `processRefund()`
- **關鍵疑慮/討論點**：[如有不確定的設計取捨請在此列出]
---
## AI 規則庫反饋 (AI Context Feedback)
- [ ] 此次 PR **無**發現 AI 重複犯錯。
- [ ] 此次 PR 發現 AI 盲點，已同步將防禦規則寫入專案設定檔（如 `.cursorrules` / `CLAUDE.md` / `AGNETS.md`）。
iThome鐵人賽
看影片追技術